Most conventional computer systems maintain an internal clock to keep track of the time of day. Accurate time of day measurements are required in a wide variety of applications, such as managing and tracking electronic mail (email), timing back-ups of data on a network, synchronizing communications between clients and servers, and managing multimedia teleconferences. Because the time clocks maintained by most computer systems tend to be subject to a certain amount of error, or "drift", it becomes necessary to synchronize such clocks to an accurate reference clock from time to time, to maintain their accuracy.
Various solutions have been developed to synchronize the time clock of a computer system. A simple method is for the user of a computer system to manually adjust the clock whenever the clock appears to have drifted. This technique, however, is both inconvenient for the user and subject to its own inaccuracies. A more sophisticated solution makes use of a server computer system operating on a network, such as the Internet. The server maintains a highly accurate time clock, such as an atomic clock, and provides accurate time readings to other computer systems on the network using a communication protocol such as Network Time Protocol (NTP). A client computer system may send a request for an accurate time reading via the Internet to an NTP server when it is necessary to synchronize its internal clock. The request may be routed to one of a number of secondary servers that function as intermediaries between client systems requiring clock synchronization and a primary NTP server. The use of such secondary servers is intended to reduce the loading on the primary NTP server. A primary NTP server may be maintained, for example, by a government entity, such as the U.S. Navy, while access to the primary NTP server is regulated by secondary NTP servers maintained by universities and business enterprises, for use by their students and employees, respectively.
A problem that is associated with many NTP based clock synchronization techniques is that the secondary servers tend to become overloaded by synchronization requests, particularly those which serve large networks. A large business enterprise, for example, may maintain a secondary time server that serves hundreds or even thousands of client systems. Hence, the occurrence of a large number of synchronization requests within a short period of time may significantly slow down operation of the server. This effect is undesirable, particularly if the server is responsible for other vital services.
Other problems associated with prior clock synchronization techniques are inconvenience to the user and disruption of the user's activities. Synchronization of a computer system's time clock is typically performed under the control of network application software executing on the computer system, which operates the computer system's communication device to access a network time server. In a home environment, in which access to the Internet is typically provided through the use of a modem, the network software must perform a modem dial out routine to establish a connection to the Internet. It is undesirable for a computer system to initiate a dial out on its own whenever clock synchronization is required, as doing so may be disruptive to the user. Consequently, network software products are commonly configured to synchronize the time clock only when it is determined that an active network connection exists. This approach has the disadvantage that, in a home situation, the time clock is synchronized only when the user actually accesses the Internet, which may not be frequent enough to maintain the accuracy of the clock.
In a business ("enterprise") environment, it is common for a direct Internet connection to be provided to computer users, albeit through their company's local area network (LAN) or other private network, such that no dial out procedure is required. However, many network applications are designed to operate in either an enterprise situation or a home situation. Consequently, network software is often conservatively designed based on the assumption that establishing a network connection will be disruptive to the user. Hence, in an enterprise situation, the operating system is commonly polled to determine whether the network software is loaded, and synchronization of the clock is performed only when the network software is loaded. As a result, even in computing environments where establishing a network connection would not be disruptive to the user (e.g., environments which require no dial out), synchronization of the time clock may not occur as often as is necessary to maintain the clock's accuracy.